-
-
Notifications
You must be signed in to change notification settings - Fork 142
feat(container): support decorators #1537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Would be nice to have built-in decorators, but not a fan of this implementation, which forces having a #[Decorates(Repository::class)]
final class CacheRepository implements Repository
{
public function __construct(
private readonly Repository $repository, // container knows to inject the original one
private readonly Cache $cache,
) {}
}Tempest would discover this class and register it as a decorator. When resolving |
Yeah, you are right. I changed it to attribute |
packages/container/src/Exceptions/DecoratorNotImplementingInterface.php
Outdated
Show resolved
Hide resolved
|
Here's a first review, but it will need @brendt's approval and review as well |
Decorator5d60826 to
55465d0
Compare
|
I'm currently working through my backlog and I'll come back to this one as soon as possible (after 2.0) |
|
I like it! Although, |
|
Very nice! Thanks |
Decorator pattern is one I'm using often and I'm really missing it in Tempest. It can be somehow emulated using initializers but it's not the same.
I added
Decoratorattributeand to decorate existing implementation
That was v1, I'll leave that for the archaeologists.
I added
Decoratorinterfaceand to decorate existing implementation
As you can see, decorated instance is indicated to discovery by return type of
setDecoratedmethod (like in Initializers).